home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 269 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  5.1 KB

  1. Path: fido.asd.sgi.com!austern
  2. From: John Max Skaller <maxtal@suphys.physics.su.oz.au>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: class.union questions
  5. Date: 05 Feb 1996 09:27:44 PST
  6. Organization: MAXTAL
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <31142255.6E5B@suphys.physics.su.oz.au>
  9. References: <v01530500ad38ee830c96@[194.163.74.11]>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: Sun, 04 Feb 1996 13:04:53 +1000
  12. X-Mailer: Mozilla 2.0b6a (WinNT; I)
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMRY+G0y4NqrwXLNJAQGebAH/USiXpKnG3E1q3tYEm2nlbncf0ekUu+Jw
  15.     KQyLbqIrCJIUnH4TpQyoub0nDERxiiwN0G2fDs17PeQhdks+RqPKIw==
  16.     =/60T
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. Dirk Becker wrote:
  20. > Hello, C++ gurus!
  21. > In Section 9.6.1 Unions [class.union] there is a large collection of
  22. > restrictions on the union itself and on candidate member classes.
  23. > I would like to ask for reasons of several of them:
  24.  
  25.     I agree, I wrote a proposal to fix this. And, three countries
  26. voted AGAINST adding yet another restriction to the list (references)
  27. causing the motion to be withdrawn -- and then reintroduced
  28. at a later meeting when two of the NB's were unable to send a delegate
  29. for financial reasons.
  30.  
  31. > a)  "A union shall not have base classes. A union shall not be used as
  32. >      a base class."
  33.  
  34.     This is in clear contravention of the clause that
  35. says a union is a class -- and says that classes can have bases.
  36. IMHO.
  37.  
  38. > This prevents any construction like the following, where one would
  39. > like to extend the union contained in some base class:
  40. > class GenericInterpreter {
  41. >     union opcode {
  42. >         short tag;
  43. >         struct { short tag; short data; } op1;
  44. >         struct { short tag; char* data; } op2;
  45. >     };
  46. > };
  47. > class SpecialInterpreter : public GenericInterpreter {
  48. >     union opcode : public GenericInterpreter::opcode {
  49. >         struct { short tag; long  data; } op3;
  50. >         struct { short tag; float data; } op4;
  51. >     };
  52. > };
  53.  
  54.    This is a very interesting idea. I'd not thought about that.
  55.  
  56. > b) "An object of a class with a non-trivial default constructor
  57. >     (_class.ctor_), a non-trivial copy constructor (_class.copy_),
  58. >     a non-trivial destructor (_class.dtor_), or a non-trivial copy
  59. >     assignment operator (_over.ass_, _class.copy_) cannot be a member
  60. >     of a union,"
  61. > This is a major reduction of the restrictions found in ARM, where all
  62. > kinds of constructors or assignment operators were excluded. 
  63.  
  64.     No. It is merely a more precise statement of the same
  65. restrictions using more technical terminology.
  66.  
  67. > c) "A union can be thought of as a class"
  68.  
  69.     Beats me how this can be, in view of the above constraints.
  70.  
  71. > In my opinion, comparing the copy constructor/assignments to others, they
  72. > are only special regarding their use by the implicitly defined memberwise
  73. > copy constructor/assignment by outside classes. Here I can't find a reason
  74. > why a member's custom copy methods should not be applicable instead.
  75.  
  76.            Absolutely. I agree. The current restrictions are valid,
  77. but the prohibition is in the WRONG PLACE.
  78.  
  79.     You SHOULD be allowed to put constructible objects
  80. in a union. All this does is prevent the compiler generating
  81. an assignment operator. So if you try to use it, you get an error,
  82. and have to define your own.
  83.  
  84. > d) anonymous union
  85. > Why is there no anonymous struct? 
  86.  
  87.     The committee (as a body) does not find arguments for 
  88. orthogonal design appealing. It is hard to demonstrate
  89. why orthogonal design is good to those who have little
  90. experience with orthogonal systems -- most of us,
  91. considering the horrid systems we're forced to work with
  92. most of the time.
  93.  
  94.     So, where Bjarne was able to provide good design
  95. we are lucky, and where he did not have time, or did not
  96. personally consider it important, or just plain
  97. messed up, we do not -- with one exception: STL
  98. (which is designed better than most parts of C++ itself).
  99.  
  100.     On a more interesting note: templates are
  101. NOT powerful enough to fix this problem (brain dead
  102. unions) BUT they are ALMOST enough. In conjunction
  103. with a header file generator program, an emulation
  104. of discriminated unions is available (mail me).
  105. Also available the logical generalisation of
  106. STL "pair" to order n.
  107.  
  108.     [I'm attempting to upgrade these facilities
  109. so they work with FUNCTIONS as well as data structures.
  110. There are some serious obstacles inherent in the
  111. non-orthogonal core language design, preventing
  112. higher order genericity from working. What I have
  113. working currently requires a generator which produces
  114. O(n^n) declarations. For example a struct of order
  115. 10 with associated generic operators is useable,
  116. the header is about 1Meg. Much above that -- needed
  117. in practical applications -- requires compiler
  118. support to "generate when required"]
  119.  
  120.  
  121. -- 
  122. John Max Skaller               voice: 61-2-566-2189
  123. 81 Glebe Point Rd              fax:   61-2-660-0850
  124. GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
  125. AUSTRALIA                      email: skaller@maxtal.com.au
  126. ---
  127. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  128.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  129.   in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  130.